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REMARKS/ARGUMENTS 

Claims 1-37 were originally pending. Claims 35-37 are withdrawn and 
canceled as belonging to non-elected subject matter. Claims 1-8, 10, 12, 16-18, 
20-21, 24-26, and 31 are amended. Claims 38-46 are added. Accordingly, claims 
1-34 and 38-46 are currently pending. The claim amendments were made to more 
particularly point out the subject matter of the invention and not to overcome any 
teachings or suggestions of the prior art. 

In view of the following remarks/arguments, withdrawal of the rejections to 
the pending claims is respectfully requested 

Claim Rejections Under 35 USC S103fa) 

Claims 1-34 stand rejected under 35 USC §103(a^ as being unpatentable 
over U.S> Patent No. 6,289,466 to Bavramoglu et al C^Bavramoglu^') in view of 
US, Patent No. 6,211.870 to Foster CFoster*\ These rejections are traversed. 

As a preliminary matter, a previous Response filed on 10/30/03 discussed 
Bayramoglu in view of Foster at length, and demonstrated the allowability of the 
pending claims over this combination, Tiiose arguments are not repeated herein, 
but are incorporated by reference. The Office is urged to reconsider those 
arguments in light of the imderstandmg gained from the following arguments. 

Independent Claim 1 recites "receiving, by a USB device, a host-specific 
device request.from an application executing on a computing device coupled to the 
USB device", "identifymg, by the USB device, a host-defined string descriptor 
defined by the application, the host-defined string descriptor being stored in 
firmware of the USB device", and "communicating, by the USB device, the host- 
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defined string descriptor to the requesting application," Nowhere do the 
references of record, singly or in combination, teach or suggest these features. 

The Action at page 3 admits that Bayramoglu does not teach or suggest "a 
host specific device request*', as claim 1 recites. Applicant agrees, especially since 
traditional USB devices are not configured to receive or respond to a request 
defined by a host of the USB device* At page 5, lines 13, the specification 
describes that "host-specific USB device requests are not provided or considered 
by the USB specification, there are no standards that allow a vendor to provide 
additional USB device-specific information in a USB device in a format that is 
determined by an operating system." 

Instead, the ACTION relies on Figs, 9 and 10, col. 7, lines 40 -60 of Foster 
for this missing feature, concluding that it would have been obvious to a person of 
ordinary skill in the art to combine the references to arrive at the claimed subject 
matter. This conclusion is unsupportable. 

The figures 9 and 10 referred to by the Action are described by Foster 
respectively as "a screen shot of a screen object layout screen" and a "screen shot 
of a custom screen object creation screen". (See, col. 3, line 64 through col 4, line 
3). These figures clearly do not teach or suggest the claimed "host specific device 
request", as claim I recites". Referring to Applicant's specification at page 15, 
lines 4-8, the specification indicates that this novel *'host-specific device request is 
used to request one of a plurality of available host-defined string descriptors from 
the device. The windex field of the host-specific device request indicates which of 
the plurality of strings are to be returned. The device returns the descriptor 
referred to by windex'' As indicated at page 16, lines 9-10, windex is used to 
identify a particular extended property descriptor", shown in Fig, 1 as element 
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122, and which as described above, is a "host-defined string descriptor**. Page 9^ 
lines 2-3, describe that "an extended property descriptor 122 is not defined in the 
USB specification." Nowhere do the figures 9 and 10 of Foster teach or suggest 
such a "host specific device request'*, as claim 1 recites. 

Now, let's take a closer look at the portion of Foster cited by the Action as 
"receiving a host specific device request". Col. 7, lines 40-60 state: 

'The remote control development software preferably stores screen objects 
in a database. The remote control development software preferably is 
provided with a number of preconfigured screen objects, and during 
installation of the remote control development software, a database of the 
preconfigured screen objects is preferably created. Preconfigxired screen 
objects provide a short cut to programming the programmable remote 
control unit 200, and may be used as templates in the development phase, 
discussed below. The preconfigured screen objects can come from an image 
table or dynamically created by software based upon functionality of the 
remote and its purpose. The database preferably can differentiate 
preconfigured screen objects fi-om custom screen objects, and deter the user 
firom editing them. 

The publisher of the remote control development software preferably makes 
available new preconfigured screen objects as new multimedia processing 
units are put on the market to further increase the ease-of- programming of 
the programmable remote control unit of the invention. The preconfigured 
screen objects may also be obtained in the aflermarket firom third parties, 
such as the vendors of multimedia processing units. 

In the learning phase, the commands for the multimedia processing unit 300 
are obtained by the remote control development software and used to 
prepare a screen object corresponding to the programmed remote control 
unit 200 A of the multimedia processing unit 300," 

Notice that this teaching of Foster's concerning remote control 
development software and screen objects is completely silent and does not suggest 
"receiving, by a USB device, a host-specific device request fi^om an application 
executmg on a computing device coupled to the USB device", as claim 1 recites. 
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Thus, the method of Claim 1 is clearly patentable over Bayramoglu and/or 
Foster, as are Claims 2-5 and 38-44, which depend therefrom and recite further 
limitations. For at least these reasons, the 35 USC §103 (a) rejection of Claims 1 
and 2-5 are improper and should be withdrawn. 

Moreover, claims 2-5 include additional features that are not taught or 
suggested by the cited combination- For instance, claim 2 recites ^Svherein the 
host-defined string descriptor comprises user interface infonnation comprises: a 
custom property section comprised of one or more custom property entries, each 
custom property entry comprising information that corresponds to a respective 
custom property for the USB device." Nowhere do the references of record singly 
or in combination teach or suggest these features. 

In addressing claim 2, the ACTION points to Fig. 6 of Bayramoglu to 
conclude that to the features of claim 2 are obvious in view of the cited 
combination. This conclusion is unsupportable. Figure 6 of Bayramoglu is "a 
screen shot of an on-screen display applet". (See, col. 4, lines 23-24). This screen 
shot of an applet does not teach or suggest the claimed "host-defined string 
descriptor comprises user interface information comprises: a custom property 
section comprised of one or more custom property entries, each custom property 
entry comprising information that corresponds to a respective custom property for 
the USB device," as Claim 1 recites*'. Instead, figure 6 shows user interface 
controls to modify screen attributes such as monitor screen size, position, and 
geometry attributes. Applicant's specification at page 15, line 23 through page 17, 
Ime 2 clearly describes one implementation of the clahned feature of "a custom 
property section comprised of one or more custom property entries" as shown 
below: 
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"The custom property section includes information corresponding to 
one or more control properties 406. Each instance of a control 
property 406 encapsulates information corresponding to a single 
custom property for the peripheral device 1 14 of Fig, 1, 
Header section 400 stores information about the remaining portions 
of the extended property descriptor 122, Header section 400 
includes the following fields: 

• dwLength — ^the total length of the extended property 
descriptor; 

• bcdVersion — ^the version number of the extended property 
descriptor; 

• windex — ^is used to identify this particular extended property 
descriptor, 

• wCount — the total number of control property entries 406 in 
the custom property section 402. 

« 

Using this information, an operating system or computer program 
application can parse the following custom property section 402, 

Custom property section 402 i s of variable size because it includes 
one or more custom property entries 406. Each control property 
section includes information that corresponds to a single custom 
property for the peripheral device 114 of Fig. 1. The custom 
property section includes the following fields: 

• dwSize — ^the total length of this particular custom property 
entry, (in one implementation, this includes header fields as well as 
name and property data.) 

• dwPropertyDataType — ^the data type of the data that is stored 
in the property data buffer (indicated below by bPropertyData field); 

• wPropertyNameLength — ^the size of the property name; 

• bPropertyName—^^ name of the property; 

• dwPropertyDatoLength — ^the total sizc of the property data; 

• bPropertyData — ^the property data. 

Clearly, the user interface controls of figure 6 used to modify screen attributes 
such as monitor screen size, position, and geometry attributes do not teach or 
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suggest the claimed * 'custom property section comprised of one or more custom 
property entries". 

For this additional reason, the 35 USC § 103(a) rejection of claim 2 is 
improper and should be withdrawn. 

Claim 3 recites 'Vherein the user interface information comprises: a 
custom property section comprising one or more custom property entries, each 
custom property entry corresponding to a respective custom property for the USB 
device", and "a header section comprising an indication of the number of custom 
property entries for which mappings exist in the custom properly section." 
Nowhere do the references of record teach or suggest these claims features. 

In addressing claim 3, the ACTION points to Fig, 6 of Bayramoglu as 
applied to claim 2, and further points to coL 8, lines 30-40 of Foster to conclude 
that to the features of claim 3 are obvious in view of the cited combination* This 
conclusion is unsupportablc. For the reasons already discussed, figure 6 of 
Bayramoglu does not teach or suggest these claimed features. Here is the cited 
paragraph from Foster: 

"Accordingly, the remote control development software displays a 
list of preconfigured screen objects, sorted or limited according to 
characteristics such as multimedia processing imit type^ 
manufacturer, and date of manufacture. The user may then select 
one of the preconfigured screen objects, and learning of the 
commands of the multimedia processing unit 300 is complete (step 
1280)." 

Clearly, these preconfigured screen objects are completely silent on *'a custom 
property section comprising one or more custom property entries, each custom 
property entry corresponding to a respective custom property for the USB device", 
and "a header section comprising an indication of the nxmiber of custom property 
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entries for which mappings exist in the custom property section", as Claim 3 
recites. 

Thus, the features of Claim 3 are patentable over Bayramoglu and/or Foster 
For these addition reasons, the 35 USC §103(a) rejection of claim 3 is improper 
and should be withdrawn. 

Claim 4 recites 'Svherein the host-defined string descriptor comprises user 
interface information comprising an icon, a font, a picture, a label, a help page^ or 
a URL." In addressing this claim, the ACTION refers the ah*eady cited portions of 
Bayramoglu and also points to Foster, col. 10, lines 50-65. For the reasons akeady 
discussed, Bayramoglu does not teach or suggest the claimed 'Tiost-defined string 
descriptor". With respect to Foster, here is the portion of Foster that is cited by 
the Action: 

"The remote control development software preferably provides drag 
and drop tools for the user to create and edit the screen object, and 
displays a tool box 1050 having a number of object creating and 
editing tools for the user to use. For example, the user could create a 
new soft key object by dragging a button tool 1052 to the display 
area 721 of the representation 726 of the programmable remote 
control unit 200. A mouse cursor 1260 is shown in FIG. 12 dragging 
a graphic of a button 1265 for the soft key object. The remote 
control development software preferably provides other object- 
oriented editing controls as known in the art. These controls pennit 
the user to modify the shape and location of soft keys, edit the 
commands associated with soft keys and programmable keys, 
change text labels, and otherwise edit the appearance of the screen 
object" 
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Nowhere does this teaching of Foster of remote control development software, 
which is on a computer that is not even on a USB device, teach or suggest the 
claimed "host-defined string descriptor, the host-defined string descriptor being 
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Stored in firmware of the USB device". Thus, the Bayramoglu and/or Foster does 
not teach or suggest any characteristic of a "host-defined string descriptor" such as 
"comprises user interface information comprising an icon, a font, a picture, a label, 
a help page, or a URL", as Claim 4 recites. 

For these additional reasons, the 35 USC § 103(a) rejection of claim 4 is 
improper and should be withdrawn. 

Claim 5 recites, *Svherein the application is an operating system/' In 
addressing claim 5, the ACTION points to the already cited portions of 
Bayramoglu and also points to Foster col 4, lines 54-59 to conclude that these 
features are obvious in view of the cited combination. This conclusion is 
unsupportable because this portion of Foster merely recites "[t]he general purpose 
computer 100 includes a processor 155 which preferably from Intel Corp. (San 
Jose, CA) and runs may Microsoft Coip, (Redmond, Washington) Windows 
operating system. In conjunction with the processor 155, the general-purpose 
computer 100 has a short-term memory 150 (preferably RAM) and a long-term 
memory 180 (preferably a hard disk) is known in the art.*' This does not teach or 
suggest '^receiving, by a USB device, a host-specific device request from an 
application executing on a computing device coupled to the USB device" 
(Claiml), and "wherein the application is an operating system*', as recited by 
Claim 5, 

Thus, the cited combination of Bayramoglu and/or Foster does not teach or 
suggest the features of claim 5. For this addition reason, the 35 USC §103(a) 
rejection of claim 5 is improper and should be withdrawn. 

Independent Claim 6 recites "querying, by a computing device coupled to a 
USB device, the USB device with a host-specific device request for a host-defined 
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String descriptor associated with user interface information stored in firmware of 
the USB device", and ^'responsive to the querying, receiving by the computing 
device, at least a portion of the user interface information." The exemplary 
arguments stated above with regard to Claim 1 are also applicable to Claim 6, For 
at least those reasons, a system of Bayramoglu that teaches exchange of 
commands based on a conventional USB specification and/or Foster that teaches 
creating screen objects for transfer to a remote hand-held device that is not 
described as even being a "USB device" may never utilize "an extended property 
descriptor", which is not specified in a conventional USB specification, and which 
claim 6 recites. 

Thus, the method in Claim 6 is clearly patentable over Bayramoglu and/or 
Foster, as are Claims 7-11 and 44, which depend therefrom and recite further 
limitations. The 35 USC § 103(a) rejections of independent Claim 6 and 
dependent Claims 7-1 1 are improper and should be withdrawn. 

Independent Claim 12 recites "[i]n a USB device that responds to device 
requests from a host, the device requests including USB-specific device requests 
with corresponding USB-specified request codes and device-specific device 
requests with corresponding device-specified request codes, the USB-specific 
device requests including a GET_DESCRIPTOR device request with a 
corresponding GET_DESCRIPTOR request code*\ ''receiving a 
GET_DESCRIPTOR device request that specifies a predetermined index, the 
GET_DESCRIPTOR device request having been received from an application 
executing on a remote computing device", and ^'responding to the 
GET DESCRIPTOR device request by returning a device-specific request code 
for subsequent use by the USB device to send an extended property descriptor 
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responsive to subsequent receipt of a host-specific device request from the remote 
computing device, the extended property descriptor specifying user interface 
information corresponding to the USB device and provided by a vendor as being 
in a data format compatible with the application," 

In addressing Claim 12, the ACTION refers the already cited portions of 
Bayramoglu and Foster, and further points to Bayramoglu, col. II, lines 37-65, 
and col 12 lines 44-65, to conclude that these features are obvious in view of the 
cited combination- For the reasons already discussed, Bayramoglu does not teach 
or suggest the claimed "host-defined string descriptor*'. As such, Bayramoglu 
and/or Fo.'fter cannot teach or suggest these following features also recited by 
Claim 12: "responding to the GET_DESCRlPTOR device request by returning a 
device-specific request code for subsequent use by the USB device to send an 
extended property descriptor responsive to subsequent receipt of a host-specific 
device request from the remote computing device". 

Here is what is further cited by the Action with respect to Bayramoglu at 
col. 11, lines 37-65: 

"77?^ CPQ^MONSYS 406 is a ring 0 USB device driver having a 
ring 3 interface. The MONITOUDLL 402 uses a Windows 
DeviceloControl Junction to communicate with the CPQJ40KSYS 
driver 406 at ring 0 . There are a number of other ring 0 modules^ 
including: a bezel board driver (CPQJSZL.SYS) 408, a legacy bezel 
board driver (BEZELVXD) 410, and an audio driver 
(CFQ_AUDSYS) 412 . These ring 0 modules further communicate 
with a single USB device driver (CFQJJSB.SYS) 414. Because all 
the functions available through the monitor bezel 206 are treated by 
the USB 126 as a single USB device, a single device driver 
(CFQJJSB.SYS) is utilized When the USB 126 identifies the 
monitor 102 connected, the CPQ_USB.SYS 414 is loaded. In turn 
CFQJJSB.SYS 414 will load CPQJIOKSYS 406, CPQJBZL.SYS 
408 , and CFQ_A UJD.SYS 412 , the monitor, bezel board, and audio 
drivers respectively. This architecture allows these three drivers to 
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sit parallel to each other rather than stacked on top of each other if 
each was treated as a separate USB function. 

The CPQJJSB.SYS driver 414 simply operates to pass USB 
commands from the higher level drivers to a USB hub driver 
(USBHUB,SYS) 416. The higher level drivers (CPQJ40N.SYS 406 , 
CPQJBZL, SYS 408, and CPQ_AUD,SYS 412 ) use Windows 
ReadFile and WriteFile functions to communicate with the 
USBHUB.SYS 416 (LSB driver stack). The USBHUB.SYS driver 416 
is a standard hub controller driver (preferably provided by 
Microsoft)". 

And Bayramoglu at col. 12 lines 44-65: 



"The BEZELDLL 404 supports a number of multimedia 
applications 422, such as a CD-ROM player, MIDI player and other 
applications requiring the bezel buttons 208. When one of the 
applications is loaded, the application 422 loads the BEZELDLL 
404 and dynamically grabs fimction pointers to obtain Windows 
\2 handles and register the bezel buttons with the application 422 . This 

way, when bezel button events are passed to BEZELDLL 404 from 
" USB 126 , BEZELDLL 404 can look up the application 422 

registered to the bezel button 208 and distribute the event to the 
appropriate application 422, In turn, the BEZEL DLL 404 loads the 
BEZELVXD and registers with the BEZELVXD to obtain a 
Windows handle. The BEZELDLL 404 communicates with the 
BEZEL. VXD 410 with Windows DeviceloControl functions. The 
BEZEL. VXD 410 communicates to the BEZELDLL 404 by posting 
Windows messages. 



When BEZEL VXD 410 is loaded, it looks for CPQ^BZLSYS 408 
,9 and CPQ_AUD.SYS 412. It performs a WriteFile to each WDM 

driver 408 and 412 to register with it and obtain a function pointer. 
20 In turn. CPQ_BZL.SYS 408 and CPQ_AUDSYS maintain the 

pointer for reciprocal communication. " 



As you can see, these cited sections of Bayramoglu do not cure the aldredy 
discussed deficiencies of the cited combination. More particularly, Bayramoglu at 
col. 11, lines 37-65, and col. 12 lines 44-65, describes architectural, execution 
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priority, and communication aspects of the system. Although program module and 
cpnvcntiQnal USB device driver communication is taught> nowhere does this 
portion or any other portion of Bayramoglu teach or suggest use of a "host- 
specific device request for a device-specific request code", as used by Claim 12. 
Instead, Bayramoglu describes at coK 12, lines 15-22 that a conventional '*Open 
Host Controller Interface Specification for USB driver" is utilized. The subject 
specification, at page 9, lines 2-3, clearly states that "an extended property 
descriptor" as Applicant claims ' Is not defined in the USB specification' ' 
(emphasis added). Thus, a system of Bayramoglu may never utilize such "a host- 
specific device request" as claim 12 recites. This is especially the case since the 
"extended property descriptor'' is not defined in the USB specification. For at 
least these additional reasons, Claim 12 is patentable over Bayramoglu and/or 
Foster, as are Claims 13-15, and 45 which depend therefi-om and recite further 
limitations.. 

Thus, the 35 USC § 103(a) rejections of Claim 12 and dependent claims 13- 
15 are improper and should be withdrawn. 

Moreover, as set forth above with respect to claims 2-5, claims 13-15 
include additional features that are not taught or suggested by the cited 
combmation. For these additional reasons, the 35 USC §103Ca) rejection of 
claims 13-15 should be withdrawn* 

Independent Claim 16 recites "communicating, by a component of an 
operating system, a non-standard USB device request to a device, the non-standard 
USB device request requesting an extended property from the device, the extended 
property providmg data that is predetermined to be compatible for use by the 
component or the operating system, the data comprising user interface information 
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associated with the USB device", and "responsive to the communicating, 
receiving, by the component, an extended property descriptor from the device, the 
extended property descriptor comprising at least the extended property." 

In addressing claim 16, the ACTION refers the akeady cited portions of 
Bayramoglu and Foster^ and then concedes that Bayramoglu does not teach or 
suggest "communicating a non-standard USB device request to a device", and 
"responsive to the communicating, receiving an extended property descriptor from 
the device, the extended property descriptor specifying user interface information 
corresponding to the USB device." Applicant agrees with the Action*s concession 
for the reasons akeady discussed. However, the ACTION continues to conclude 
that *fhe obviousness for receiving extended properties (and their corresponding 
descriptors) to include user interface specific Information is shown in paragraph 4 
of the OfBce Action, using Foster. Applicant disagrees for the reasons aheady 
discussed. Nowhere does Foster teach or suggest "communicating, by a 
component of an operatmg system, a non-standard USB device request to a device, 
the non-standard USB device request requesting an extended property from the 
device, the extended property providing data that is predetermined to be 
compatible for use by the component or the operating system, the data comprising 
user interface information associated with the USB device", as claim 16 recites. 

Instead, Foster teaches that a user creates a user interface (UI) on a 
computer coupled to a remote control device and subsequently downloads the UI 
to the remote control device for display by selecting *'a download command", 
which causes the generated UI to be installed onto the remote control unit* For 
instance, Foster teaches diat responsive to placing a remote control unit into a 
docking station connected to a general-purpose computer, the remote control unit 



30 



UK4 BAYK^PUf 



MS1-70SV3M92 



PAGE 33/38 * RCVD AT 7/1212004 7:25:49 PM [Eastern Daylight Time] ' SVR:USPT0-EFXiV-1/2 * DNIS:8729306 * CSID:303S3!I0271 * DURATiON (mm-ss):10-38 



JUL 12 2004 17:35 FR LEE fiND HPYES -PLLC 3035390271 TO 17038729306 P. 34/38 

Appl. No. 09/745,385 

Reply to Final OA of February 10, 2004 



1 

2 
3 
4 
5 
6 
7 
8 
9 
10 

u 

\2 
13 
14 
IS 
16 
17 
1« 
19 

20 

21 

22 

23 

24 

25 



and computer establish a connection that a user can later use to communicate the 
UI to the remote control unit. To this end, Foster at coL 6, lines 4-9, that "[t]he 
docking station 130 is coupleable to the I/O interface 115 of the general purpose 
computer 100, preferably in conformance with an interface standard which is 
common such as serial or USB," Thus, Foster teaches that the USB host 
computer 100 communicates with the USB docking station device 130 via a 
conventional USB interface- 
Conventional USB interfaces specify standard USB commands and do not 
specify *'a non-standard USB device request*', as claim 16 recites. Thus, a system 
of Foster that teaches exchange of commands based on a conventional USB 
specification may never utilize "a non-standard USB device request", which is not 
Specified in a conventional USB specification, and which claim 16 recites. For 
this reason alone, the references of record do not teach or suggest the features of 
claim 16. 

Accordingly, the 35 USC §103(a) rejection of claim 16 ovor Bayramoglu in 
view of Foster is improper and should be withdrawn. 

As an additional matter, at page 5, the Action addresses "a non-standard 
USB device request", as claim 16 recites, by asserting that to the extent that these 
features are "extra or extended to what is shown in Bayramoglu et al, the 
Examiner takes Official Notice that a non-standard USB request would be used, in 
order to provide flexibility to receive extended properties." 

Thus, the Action, after admitting that Bayramoglu dots, not teach or suggest 
"a non-standard USB device request**, seemingly relies on personal knowledge to 
incorporate these missing features into Bayramoglu and thereby modify the 
reference to something that is not taught or suggested in an attempt at arriving at 
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the claimed "extended property descriptor" without pointing to any specific 
teaching or suggestion. For the reasons aheady provided^ the cited combination of 
Bcxyramoglu and/or Foster does not teach or suggest any USB command 
communication beyond that described in a conventional USB specification . 
Additionally, the references of record are completely silent with respect to any 
^'extended properties" anything. 

Since the Office is seemingly relying on personal knowledge: 

"fwjhen a rejection in an application is based on facts within the 
personal knowledge of an employee of the office, the data shall be as 
specific as possible, and the reference must be supported, when 
called for by the applicant, by the affidavit of such employee, and 
such affidavit shall be subject to contradiction or explanation by the 
affidavits of the applicant and other persons," 37 CFR 
§L 104 (d)(2). 

If this rejection is maintained on a similar basis in a subsequent action, it is 
respectfully requested for the Examiner to supply an affidavit to support this 
modification to the cited combination to arrive at what the Action has aheady 
admitted are features missing from the cited references, and features that are 
recited in claim 16. 

Dependent Claims 17-20 depend from claim 16 and are allowable over the 
references of record by virtue of this dependency. For this reason alone, the 35 
use §103(a) rejection of claims 17-20 over Bayramoglu in view of Foster is 
improper and should be withdrawn. 

Moreover, as set forth above with respect to claims 2-5, claims 17-20 
include additional features that are not taught or suggested by the cited 
combination. For these additional reasons, the 35 USC § 103(a) rejection of 
claims 17-20 should be vidthdrawn. 
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Claim 21 recites "an extended property descriptor stored in the memory, 
the extended property descriptor identifying a set of user interface information 
corresponding to the USB device and in a data format predetermined to be 
compatible for use by a requesting application executing on a remote computing 
device", and "a control program module stored in the memory, the control 
program module being configured to send the extended configuration descriptor to 
a requestor in response to receiving a host-specific device request at the port," 
For the reasons already discussed above, the cited combination docs not teach or 
suggest these claimed features* 

Accordingly, the 35 USC §103(a) rejection of claim 21 is improper and 
should be withdrawn. 

Claims 22-24 depend from claim 21 and are allowable over the references 
of record by virtue of this dependency. For this reason alone, the 35 USC § 103(a) 
rejection of claims 22-24 over Bayromoglu and/or Foster is improper and should 
be withdrawn. 

Moreover, as set forth above with respect to claims 2-5, claims 22-24 
include additional features that are not taught or suggested by the cited 
combmation. For these additional reasons, the 35 USC § 103(a) rejection of 
claims 22-24 should be withdrawn. 

Claim 25 recites "receiving a request from an application program for a 
descriptor that specifies user interface infomiation in a data format predetermined 
to be compatible for use by the application program and corresponding to the USB 
device", **querying the USB device with a host-specific device request to obtain 
the property descriptor", "responsive to the querying, receiving the descriptor", 
and '"providing the received property descriptor to the requesting application 
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program," For the reasons already discussed above, the cited combination does 

not teach or suggest these claimed features. 

Accordingly, the 35 USC §103(a) rejection of claim 25 over Bayramoglu 

and/or Foster is improper and should be withdrawn- 
Claims 26-30 depend from claim 25 and are allowable over the references 

of record by virtue of this dependency. For this reason alone, the 35 USC § 103(a) 

rejection of claims 26-30 over Bayramoglu and/or Foster is improper and should 

be withdrawn. 

Moreover, as set forth above with respect to claims 2-5, claims 26-30 
include additional features that are not taught or suggested by the cited 
combination. For these additional reasons, the 35 USC § 103(a) rejection of 
claims 26-30 should be withdrawn. 

Claim 31 recites *Veceiving a host-specific request for an extended property 
descriptor from a requestor, the extended property descriptor indicating one or 
more user interface elements that correspond to the USB device, the one or more 
user interface elements being predetermined to be compatible for use by an 
application executing or for execution on a remote computing device", and 
'^responsive to the receivings communicating the extended property descriptor to 
the requestor." For the reasons akeady discussed above, the cited combination 
does not teach or suggest these claimed features- 

Accordingly, the 35 USC §103(a) rejection of claim 30 over Bayramoglu 
md/ot Foster is improper and should be withdrawn. 

Claims 32-34 depend from claim 31 and are allowable over the references 
of record by virtue of this dependency. For this reason alone, the 35 USC § 103(a) 
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rejection of claims 32-34 over Bayramoglu and/or Foster is improper and should 
be withdrawn. 

Moreover, as set forth above with respect to claims 2-5, claims 32-34 
include additional features that are not taught or suggested by the cited 
combination. For these additional reasons, the 35 USC § 103(a) rejection of 
claims 32-34 over Bayramoglu md/or Foster should be withdrawn. 

New claims 38-46 depend ftom respective ones of mdependent base Claims 
1, 6, or 12, and are patentable over Bayramoglu and/or Foster at least for the 
reasons presented above. 

Conclusion 

Pending Clahns 1-34 and 38-46 are in condition for allowance and action to 
that end is respectfully requested. Should any issue remain that prevents 
allowance of the application, the Office is encouraged to contact the undersigned 
prior or issuance of a subsequent Office action. 



Respectfully Submitted, 



Dated: ^/^/^ ¥ 




Jrian G, 

Reg. No. 44, 421 
(303) 539-0265x241 
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